Automated tests for electronic control systems have been widely introduced and are widely known these days. For the automation of tests of that kind, various techniques, pieces of equipment and strategies of different manufacturers and self-developed ones are used. In this context, the required interfaces between the test cases, which implement the automated tests, and the test system which produces the access to the unit to be tested, known from here on as the test specimen, are specific to the manufacturer and are proprietary.
This gives rise to a series of problems. For one thing, test cases are not able to be developed independently of the test system used. A change or an exchange of the test system used generally makes it necessary to adapt the test cases. Such an adaptation may, under certain circumstances, be very costly, since the test cases, in general, directly call up the proprietary interfaces of the test systems, and the interfaces of the respective test systems differ widely from one another. Because of this, the preparation of logical test cases that are independent of a respective test system is made more difficult. An exchange of tests or test cases between control unit manufacturers and their customers is only possible in a simple manner if both partners use identical test systems. In this context, the reuse of test cases is severely limited.
Furthermore, the reuse of test systems is also not possible in a simple way. Test cases have to be implemented in test description language or a test sequence control supported by the test system used. If a test description language or a test sequence control is not supported by the test system used, then first of all a costly transfer or port of the test cases into the language or sequential control supported by the test system has to take place before the test system is able to be used for the present test or test case. Under certain circumstances such a port is very costly or is not possible technically, so that the test system cannot be used for the test or the test cases.
Furthermore, in many known design approaches, a test case is, in addition, strictly connected to a certain variant of the unit to be tested, or the test specimen. Thus, in these cases, for example, concrete physical addresses are coded for access to input and output signals of the test specimen. The reuse of these test cases for various variants of the test specimen is made difficult thereby, or even impossible.
ETSI (European Telecommunications Standards Institute) has standardized a test description language designated as TTCN in ETSI ES 201 873-1 to -4. This test language makes possible the preparation of test cases independent of the test system used in this connection. The test system is accessed via so-called ports. In this context, a port is a set of signatures which will be designated as test steps below. A test step, in this context, is a certain function that may be called up by a test case in order to stimulate and gage a test specimen, such as an electronic control unit. In this context, for instance, a functionality may be involved that reads a fault storage of the test specimen or the control unit. TTCN-3 directly accesses the test system used via so-called system-under-test adapters or platform adapter. In this context, the two adapters, that is, the system-under-test adapter and the platform adapter, are components of the executable program generated from TTCN-3. Because of this, if there is a change in the test system, a new generation of the executable program is also necessary. Furthermore, the test steps able to be called up are limited to test description language TTCN-3.